The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Geographically dispersed enterprises often deploy distributed computer systems in order to enable information sharing throughout the enterprise. Such distributed systems generally comprise an enterprise network, which includes a number of Local Area Networks (LANs) that are connected over one or more Wide Area Network (WAN) communication links. An enterprise network generally includes one or more servers that store enterprise information in one or more data resources. The servers supply the data from the resources upon receiving requests for the data from other enterprise servers or clients, which servers or clients may be established in the LAN that is local to the data resource or may be established in a LAN that is located across the WAN.
For example, the business structure of an enterprise may comprise a main office, and one or more branch offices. To support this business structure, the enterprise typically employs a local LAN for each of the main and branch offices, and one or more WAN communication links that connect the LANs at the branch offices with the LAN at the main office. This network infrastructure enables users at the branch offices, who run software applications locally on their workstations, to access files that are located at the main office.
While this network infrastructure allows for greater sharing of information for users throughout the enterprise, it also has a significant disadvantage because software applications that access files are primarily designed to access the files over a relatively high-speed LAN. Usually, significant latency and performance degradation are observed when a software application opens a file that is located across the WAN in a remote LAN. In a typical example, an enterprise user in a branch office uses a word-processor application to open and modify files. The user is able to open files that are in the LAN local to the user relatively quickly, while opening files that are located across the WAN in a remote LAN is slow and sometimes unreliable.
One of the reasons for the above-described performance degradation is the high number of messages exchanged over the WAN communication link between a file server that manages a file and a client that executes an application that attempts to open the file. A typical file open operation requires the client application and the file server to exchange a series of messages before the file server grants access to the file. When the client on which the client application executes and the file server are coupled over a WAN communication link, the network latency introduces undesirable or even unacceptable delay in completing the file open operation because of the time needed to communicate the series of messages over the communication link. Even if the WAN communication link has sufficient bandwidth, the WAN latency still causes the file open operation to be slow. As a result, the response times for the user are too high.
Furthermore, some client applications use a synchronous series of messages to perform file open operations, that is, the client applications do not send the next message until the response from the previous message has been received. This creates a further delay in opening the file. During the time in which a client application is waiting to send the next message, the communication link between the client and the file server is underutilized, which in turn may delay the transfer of any other data between the client and the file server. This problem is exacerbated when the client application performs a burst of file open and file close operations in a rapid succession as part of the same user session. The number of messages between the client and the file server increases when the number of file open and file close operations performed by the client application increase.
The above-described performance problems caused by the high number of exchanged messages are not unique to WAN communication links. Similar problems of high latency and high response times are observed by client applications that transfer data over other low bandwidth and/or high latency communication links, such as, for example, dial-up connections, Digital Subscriber Line (DSL) connections, and Integrated Services Digital Network (ISDN) connections.
One past approach for reducing the number of messages exchanged between a client application and a file server while opening a file is the Batch Oplocking mechanism of the Common Internet File System (CIFS) protocol. Batch Oplocking allows the client to skip extraneous file open and file close operations requested by a client application. For example, when a client application executing on Client A opens a file on a file server, Client A may request a batch oplock from the file server. The batch oplock is a lock on the file that is maintained by the file server. Provided that the file is not open at the file server by any other client, the file server grants the batch oplock to Client A. Client A then may keep the file open on the file server for the client application across multiple file open and file close operations performed by the application. When another client, Client B, requests from the file server to perform any file operation on the file, the file server notifies Client A. At this point, Client A must release the batch oplock and must synchronize the file with the file server. In addition, if the client application believes that the file is actually closed (for example, when the last request from the client application to Client A was a file close operation), Client A must also close the file on the file server.
The Batch Oplocking mechanism has numerous significant disadvantages. One disadvantage is that the batch locks granted by the file server correspond to the exact type of the access request issued by the client application. If the same client application later requests a different type of access to the file, the file server must break the granted batch oplock, and must issue a new batch oplock that corresponds to the type of the new request. For example, if the original request from the client application was only to modify the attributes of the file, and the subsequent request was to read data from the file, the file server must revoke any batch oplock that was granted along with the response to the original request. In this way, the same client application effectively looses its own batch oplock on the file in response to its own subsequent request, which does not result in any significant reduction in the number of messages exchanged between the client and the file server.
Another disadvantage of the Batch Oplocking mechanism is that once a client loses a batch oplock on a file granted by a file server, the client cannot regain the oplock while the client is holding the file open. The client must close the file on the file server, and must request a new batch oplock using a new file open request. The server will grant the new oplock only if no client (including the client that broke the previous batch oplock) is holding the file open. This makes the obtaining of a batch oplock a “one shot” mechanism after which the process for obtaining a new batch oplock must be restarted, and this process does not result in any significant reduction in the number of messages exchanged between the client and the file server.
Another disadvantage is that the Batch Oplocking mechanism is opportunistic, that is, a client must release its batch oplock on the file and/or close the file as soon as another client requests to perform an operation affecting the file. For example, the file server must notify a client that holds a batch oplock, and must break the oplock when another client attempts to rename or delete the file or attempts to rename or delete the file's parent directory. This process not only does not result in any reduction in the number of messages exchanged between the client and the file server, but actually increases the number of exchanged messages because the file server needs to send extra messages to notify clients holding batch oplocks on a file when other clients attempt to perform operations affecting the same file.
Based on the foregoing, there is a clear need for a technique of reducing client-server messages associated with opening a file that overcomes the problems described above and the disadvantages of the described past approach.